Web Design & Development

Ein paar Seiten lang warten

Oder: Wir warten aufs Internet!

Henning Fries

„Das dauert ja wieder lange, bis die Seite geladen ist – diese App ist aber zäh.“ Diese Aussagen verwenden wir unbewusst fast täglich, aber warum? Wie erleben wir Ladezeiten und Reaktionszeiten von Websites und Apps? Für jede einzelne Zehntelsekunde wird getweakt, refactort und getunt. Aber warum spielen Zeit und Performance so eine wichtige Rolle? Warum warten wir nicht gerne oder verlassen Websites, wenn uns die Wartezeit zu lange erscheint und nervt? Und wenn wir warten, wie erleben wir diese Wartezeit? Was können wir tun, um das Erleben der Wartezeit zu optimieren?

Neben den oft beschriebenen technischen Feintunings spielen psychologische und neurowissenschaftliche Aspekte für das Erleben von Ladezeiten eine entscheidende Rolle. Reichte früher noch ein Ladebalken oder Spinner, geht der Trend heute zu Skeleton-Content à la Facebook und Slack. Der nachfolgende Artikel beinhaltet Denkmodelle zum Thema Zeiterleben und wie über technische Leistungsoptimierungen hinaus Psychologie und Wahrnehmungsmanagement dabei helfen können, das Erleben von Wartezeiten positiv zu beeinflussen.

Irgendwie warten wir sowieso fast immer … jetzt auch schon in einem Artikel. Wir warten auf öffentliche Verkehrsmittel, die bestellten Pakete oder auf die große Liebe. Warten betrifft uns alle! Allerdings benötigt man zum Warten eine wichtige Grundvoraussetzung: Man braucht Zeit.

Wenn ich an Zeit denke, habe ich gleich einen Ohrwurm aus meiner Kindheit im Sinn. Im Jingle zur Fernsehserie „Es war einmal der Mensch“ wurde die Frage gestellt „Was ist Zeit? Ein Augenblick? Ein Stundenschlag? 1 000 Jahre sind ein Tag!“ Vergeht die Zeit zu schnell, neigen wir zu Formulierungen wie „Ach, wie die Zeit vergeht …“ oder „die Zeit verfliegt“. In geologischen Zeiträumen gemessen, in denen zwischen einzelnen Erdzeitaltern gut und gerne einmal 77 Millionen Jahre vergehen, kann man schon einmal sagen, dass 1 000 Jahre ein Tag sind. Doch wir sind schnelllebig geworden und Zeit ist ein kostbares Gut, von dem wir meist viel zu wenig haben! Warten ist gesellschaftlich als unproduktive Zeit konnotiert, daher kann eine halbe Minute auch mal ganz schnell zu einer halben Ewigkeit werden und gerade im Kontext von Webseiten und Programmierung wissen wir das alle nur allzu gut.

Noch mehr Expertentipps mit unserem kostenlosen Newsletter

Gehen wir dem Zeitbegriff also einmal etwas auf den Grund. Benjamin Franklin fasste 1748 das Credo des Industriezeitalters mit seinen Rationalisierungsbestrebungen in wenigen Worten zusammen: Time is money – Zeit ist Geld. Und wann immer wir warten, sind wir unproduktiv … Doch Zeit ist wesentlich vielschichtiger. Im Rahmen des Zeitbegriffs kann nämlich zwischen objektiver und subjektiver Zeit unterschieden werden.

Objektive und subjektive Zeit

Objektive Zeit, oft auch profan als Uhrzeit bezeichnet, ist die objektiv messbare Zeit. Sie verläuft für uns zumindest im durchschnittlichen linearen Erfahrungsraum kontinuierlich, vollkommen gleichmäßig. Die Gegenwart stellt dabei nur den winzigen Durchgangspunkt zwischen Vergangenheit und Zukunft dar (Die Relativität interessiert uns an dieser Stelle nicht). Die objektive Zeit basiert auf naturwissenschaftlichen und astronomischen Konzepten und wird als Konvention zur Strukturierung und Messung von Aktivitäten herangezogen. Die Messung erfolgt anhand metrischer, gleichmäßig gerichteter Einheiten, die von astronomischen und atomaren Bewegungen abgeleitet werden. Ihr bekanntestes Symbol ist die Uhr.

Die subjektive Zeit kann als Gehirnzeit bezeichnet werden. Sie verläuft erlebnismäßig sehr unterschiedlich. Die Gegenwart ist nicht nur ein punktförmiges Erleben, sondern hat durchaus eine bestimmte Zeitdauer. Diese subjektive Zeit tritt auf, wenn ein Individuum eine objektive Zeit einschätzt, und wird durch verschiedenste Faktoren wie z. B. die momentane Stimmung usw. beeinflusst. Die subjektive Zeit kann sich dabei auf einen Zeitpunkt oder eine Zeitspanne beziehen.

Kognitive Stapelverarbeitung

Zeit lässt sich erleben und kann als eine Folge von Ereignissen angesehen werden. Jedes Ereignis besteht dabei aus unzähligen Einzeleindrücken. Unser Gehirn ist ein wahrer Meister darin, diese einzelnen Impressionen für uns aufzuarbeiten und verständlich zu machen. Ein bekanntes Beispiel – nicht nur für Designer –, das die Stapelverarbeitungsfähigkeiten unseres Gehirns gut veranschaulicht, kommt aus der Gestaltpsychologie (und hat eigentlich gar nichts mit Zeit zu tun).

Abb. 1: Figur und Grund – Wer sieht den Dalmatiner? [1]

 

Das Gestaltprinzip von Figur und Grund – das Bild vom gepunkteten Dalmatiner (Abb. 1) gilt in der Psychologie als Beispiel für die ganzheitliche Erfassung der Gestalt in der Wahrnehmung. Es werden hier nicht zuerst die einzelnen Gliedmaßen erkannt und erst dann zum Hund zusammengesetzt, sondern das Bild aus den dunklen und hellen Flächen emergiert. Unser Gehirn ist schon phänomenal. Und auch was unsere Erinnerungen angeht, macht das Gehirn ein paar kuriose Dinge …

Kurzzeitgedächtnis

Wie erinnern wir uns an die erlebte Zeit im Kurzzeitgedächtnis? Auch hier verhält sich das Gehirn äußerst kurios und bei Weitem nicht intuitiv. Ereignisse, die Spaß gemacht haben und fesselnd, aber kurz waren, werden uns als lang in Erinnerung bleiben, wohingegen wir uns an eintönige Ereignisse, bei denen nichts passiert ist, als kurz erinnern.

Um das zu verstehen, stellen wir uns den Erinnerungsspeicher als komprimiertes ZIP-Archiv vor. Das Gehirn komprimiert lange Ereignisse, beispielsweise eine lange, monotone Autofahrt. Die Erinnerungen an all die Nummernschilder, die man gesehen hat, wären ziemlich überflüssig und nutzlos in unserem Erinnerungsspeicher. Als Nebeneffekt empfinden wir später die vergangene Zeit als wesentlich kürzer. Ergo erscheinen uns im Kurzzeitgedächtnis monotone Events im Nachhinein kürzer als sie eigentlich waren. Cooler Trick. Wir schauen uns aber jetzt eine besondere Form des Zeiterlebens an: das Warten.

User Experince Design Track auf der webinale

Warten als Sonderform des Zeiterlebens

Im Duden wird warten als schwaches Verb geführt, bei dem einem Ereignis entgegengesehen wird, man sich brav an einem Ort aufhält, bis sich etwas ereignet, oder irgendjemand kommt (in diesem Fall wird man gewartet, da der- oder dasjenige dafür sorgt, dass wir warten müssen). Eine weitere Bedeutung von warten wird häufig vergessen, nämlich etwas aktiv hinauszuzögern bzw. vor sich her zu schieben. Eine weitaus schönere Definition liefert uns Dr. Andreas Göttlich, ein Soziologe an der Uni Konstanz. Er definiert warten als das „Erleben von Zeit“. Ich würde an dieser Stelle sogar noch einen Schritt weiter gehen und sagen „Warten ist das bewusste Erleben von Zeit“. Warten fordert uns und unsere Geduld. Und Warten ist von äußeren Umständen abhängig, etwa davon, wie und worauf und auch wo wir warten.

Beim Begriff „warten“ denken viele sofort an eine Warteschlange – den Inbegriff des Wartens. Die Warteschlange ist eine englische Erfindung mit soziologischem Tiefgang. In der Warteschlange spiegelt sich ein egalitäres gesellschaftliches Grundprinzip wider. In der Schlange zählt nicht der gesellschaftliche Stand, sondern wer zuerst kommt mahlt zuerst – „first come, first served“. Die Zeit eines jeden Menschen in der Schlange ist gleich viel wert – jetzt seht ihr die Warteschlange sicher mit ganz anderen Augen.

Aber wir warten nicht immer nur in einer Schlange. Wir warten in Meetings, wir warten in unserer Freizeit, in der Kneipe, im Restaurant, im Café etc. Wir warten im Verkehr, ob im Stau, an der Ampel, am Zebrastreifen oder am Bahnhof oder Flughafen, weil das Transportmittel Verspätung hat. Wir warten im Sport, dort wird warten sogar als Strafe eingesetzt. Und letztendlich warten wir in stickigen Räumen oder kalten Fluren auf Ärzte oder bürokratische Akte. In all diesen Situationen verbringen wir Wartezeit. Und gerade diese Wartezeit ist interessant, denn sie gestaltet sich je nach Ausprägung unterschiedlich.

Wartezeiten …

… fühlen sich unbeschäftigt länger an als beschäftigt.
… fühlen sich, wenn ungewiss, länger an als bekannt.
… fühlen sich ungeklärt länger an als erklärt.
… fühlen sich je nach Gefühlslage länger an.

Warten bedeutet Unterbrechungen im Zeitfluss. Daraus entsteht Ungeduld, heute verstärkt durch unser verschärftes Zeitnutzungsprinzip, Zeit effizient, produktiv und optimiert zu nutzen. Bei meinen Vorträgen mache ich gerne ein Experiment und unterbreche den Zeitfluss mitten im Vortrag. Ich lasse das Auditorium einfach nur warten, ohne Smartphone oder etwas zu lesen, und anschließend schätzen, wie lange die objektive Wartezeit war. Dabei erleben die Zuhörer eine unbeschäftigte Wartephase, ein unbeschäftigtes Zeiterleben. Dieses unbeschäftigte Warten wird von einer großen Mehrheit subjektiv als wesentlich länger empfunden als die eigentliche Wartezeit war.

Smartes Warten

Gerade Smartphones dokumentieren die Schwierigkeiten unserer modernen Gesellschaft mit dem Warten. Als Fluch oder Segen scheinen sie zumindest die Lösung dafür zu sein. Smartphones geben uns die Möglichkeit, die Zeit, in der wir warten, aktiv zu überbrücken, denn Wartezeit wird in aller Regel als unangenehm erlebt. Wer wartet schon gerne? Warten bringt Selbstreflexion und Emotion mit sich. Auch hierzu liefert der Soziologe Dr. Andreas Göttlich ein passendes Statement: „Warten, kann man generell sagen, ist ein Phänomen oder eine Verhaltensform, die ganz selten eigentlich wertneutral verläuft. Also Warten ist oftmals emotional aufgeladen, und hoffen und fürchten beschreiben eben solche emotionalen Aufladungen des Wartens, das hängt natürlich davon ab, wie wir das Erwartete dann bewerten“.

Emotionen spielen also eine entscheidende Rolle, und jetzt kommt der Brückenschlag zum mobilen Web bzw. zum Web allgemein: Was ist, wenn wir auf den Smartphones, mit denen wir eigentlich die Wartezeit überbrücken wollten, auf einmal warten müssen – schlechte Verbindung, langsame Website?

Die digitale Warteschleife

Eine interessante Studie aus dem Jahr 2014, die sog. Mobile Web Performance Stress Studie, förderte zutage, dass unter der Gesamtzahl der Probanden 23 Prozent ihr Smartphone verfluchten, wenn ihnen etwas zu langsam erschien. 11 Prozent schrien es an und 4 Prozent warfen es sogar zu Boden. Wir haben anscheinend die Fähigkeit zu warten verlernt bzw. die Gelassenheit verloren. Es geht hier nämlich nicht um Stunden, sondern um Sekunden! Die Größen in Kilobyte der durchschnittlichen Websites hat sich in den Jahren von 1996 bis 2016 stark verändert. Begonnen bei 14,1 kB im Jahr 1996 war man 2016 bereits auf 2,5 MB! Jetzt allerdings kommt das Paradoxon: Waren nach Industriestandard 1996 noch 8 Sekunden erlaubt, um die knapp 20 kB zu laden, müssen 2016 die 2,5 MB Daten bereits in 1 Sekunde auf dem Bildschirm sein. Prognosen für 2019 konstatieren, dass die durchschnittliche Websitegröße bei etwa 4 MB liegen wird (und am besten haben wir die in 0,5 Sekunden fertig auf dem Bildschirm gerendert).

Vereinfacht kann man sagen, das Laden von Daten erzeugt Warten, ergo ist laden gleich warten. Fast täglich werden wir mit irgendwelchen Ausprägungen von Fortschrittsbalken konfrontiert. Wir visualisieren das Warten, machen es sichtbar und erlangen damit Kontrolle über die Zeit. Das Schlimmste, was einem Wartenden passieren kann ist, dass man auf einmal feststellt, dass einfach nichts passiert. Man kommt aus dieser Situation womöglich nie wieder heraus. Durch den Fortschrittsbalken arrangiert man sich mit dem Warten und freut sich, das Gefühl zu haben, irgendwann ans Ziel zu gelangen und die Website oder das Programm heruntergeladen zu haben. Doch frei nach dem hinlänglich aus dem Fußball bekannten Spruch: Nach dem Ladebalken ist vor dem Ladebalken.

Wahrgenommene Performance

Ein aufgabenorientierter Prozess zeichnet sich dadurch aus, dass wir die Absicht haben, etwas zu tun, es tun und letztendlich unser Tun beantwortet wird. Dazwischen ist, wer hätte es gedacht, warten angesagt. Dieser aufgabenorientierte Prozess hat eine Performance, also wie reaktiv und schnell uns dieser Prozess vorkommt. Wir befinden uns in den Sphären der subjektiven, der wahrgenommenen Zeit und schauen demnach auch auf die wahrgenommene Performance eines solchen Prozesses. Diese lässt sich als Funktion aus der erwarteten Performance (also dem, was wir für die Erledigung der Aufgabe für angemessen erachten), der eigentlichen Performance (also was Backend, Frontend, Rechenleistung, Netzwerk etc. so hergeben) und der User Experience definieren. Metriken, Millisekunden und Kilobytes sind nur ein Teil des großen Ganzen. Gehirn und Benutzererfahrung spielen eine wichtige Rolle!

Es geht nicht nur um Millisekunden, Frames und Megabytes. Es geht darum, wie diese Millisekunden, Frames und Megabytes dazu beitragen, wie der Benutzer die Applikation wahrnimmt. Es geht um Wahrnehmung! Performance ist (eine Form der) Wahrnehmung.

Schauen wir uns vier Zeitintervalle genauer an. Diese tauchen u. a. in „Powers of 10: Time Scales in User Experience“ des Usability-Gurus Jakob Nielson auf:

0,1–0,2 s: Dieses Intervall ist die maximale Dauer zwischen Aktion und Reaktion, die vom Benutzer aka Menschen als unmittelbar erkannt wird.

0,5–1 s: Die maximale Antwortzeit für eine sofortige Reaktion. Diese Zeitspanne entspricht normalerweise der Antwortzeit eines Gesprächspartners in einer zwischenmenschlichen Kommunikation.

Innerhalb dieses Intervalls muss ein Benutzer Feedback auf eine Aktion bekommen, z. B. einen Klick, wenn das Signal nicht schon im vorhergehenden Intervall verarbeitet wurde. Ansonsten ist es irgendwie komisch.

2–5 s: Diese Zeitspanne definiert den User Flow bzw. die optimale Erfahrung oder Immanenz, wenn der Benutzer absolut fokussiert und vertieft in einer Aktivität aufgeht.

5–10 s: 2015 erregte eine Microsoft-Studie einiges Aufsehen, die postulierte, dass die durchschnittliche Aufmerksamkeitsspanne des Menschen von 12 auf 8,25 Sekunden gefallen ist. Das ist eine Sekunde weniger als die Aufmerksamkeitsspanne eines Goldfischs. Sehen wir mal nicht so schwarz und gehen der Einfachheit halber von 10 Sekunden durchschnittlicher Aufmerksamkeitsspanne aus. Danach ist man zwar noch irgendwie an der Aufgabe dran, lässt sich aber leichter ablenken. Greift das System jetzt nicht in irgendeiner Form motivierend ein, dann ist der Benutzer weg – mental und ggf. auch physisch.

Google legt die Messlatte bei der Definition der Zeitintervalle schon etwas höher (Tabelle 1). Dort wird ab 100 ms schon das erste Mal von einer Verzögerung gesprochen. Bei mehr als einer Sekunde redet man dort schon von einem Kontext-Switch, dass der Benutzer also schon über das nächste Ding nachdenkt. Nach 10 Sekunden denkt man, es sei kaputt!

DelayUser Perception

0 to 100 ms Instant
100 to 300 ms Slight Perceptile Delay
300 to 1 000 ms Task Focus, Perceptible Delay
1 s+ Mental Context Switch
10 s+ I’ll come back later… not
Tabelle 1: User Perception of Performance Delays

An dieser Stelle zitiere ich Denys Mishunov, der zum Thema Perceived Performance tolle Vorträge gehalten und auch einige interessante Artikel verfasst hat, die mir bei der Recherche zu diesem Artikel sehr geholfen haben: „Users usually don’t care about your objective time!“

Und irgendwie hat er recht. Greifen wir lieber also zuerst einmal zur Psychologie, bevor wir zur IDE greifen.

Herr Weber

1834 bemerkte der Physiologe Ernst Heinrich Weber, dass ein Sinnesorgan ab einem bestimmten Intensitätsbetrag eine Veränderung registriert. Man stelle sich vor, man kommt in einen Raum, der durch zehn Kerzen beleuchtet ist. Wenn nun eine elfte Kerze angezündet wird, kann man den Helligkeitsunterschied wahrscheinlich noch gut wahrnehmen. Sind es aber von Beginn an hundert Kerzen und man macht die 101. Kerze an, dann ergibt sich wahrscheinlich kein Helligkeitsunterschied (Beispiel von Galanter, 1962).

Ernst Heinrich Weber war der Erste, der entdeckte, dass die Unterschiedsschwelle nicht konstant ist, sondern vom Ausgangsreiz abhängig ist, die sog. Weber-Konstante.

Bekannt wurde die Weber-Konstante oder der Weber-Bruch im Rahmen der Weiterentwicklung von Webers Forschungen durch den Begründer der Psychophysik Gustav Theodor Fechner. „[…] die Unterschiedsschwelle markiert die minimale Änderung der Reizenergie, die durch einen Beobachter noch entdeckt werden kann …“ [2].

Anhand eines Gewichtsunterschiedes lässt sich die Unterschiedsschwelle recht einfach erklären: dort braucht man 2 Prozent Unterschied zum Ausgangsreiz. Das bedeutet, bei 50 g müssen wir 1 g drauflegen, um einen Unterschied zu bemerken. Bei 5 kg sind es schon 100 g, damit wir eine Gewichtszunahme bemerken.

Erfreulich ist, dass sich diese Gesetzmäßigkeit auch auf zeitliche Ereignisse bzw. auf ein Konstrukt wie Ladezeit anwenden lässt. Vereinfacht (wie immer gibt es Varianzen) liegt die Unterschiedsschwelle bei etwa 20 Prozent nach oben und nach unten! 20 Prozent mehr oder weniger spielen keine Rolle. Auf ein Zeitintervall von 5 Sekunden angewendet, macht eine Sekunde mehr oder weniger keinen Unterschied in der Wahrnehmung.

Timelords der Wartephasen

Ausgestattet mit diesem Wissen können wir nun, wie wahre Timelords, die Zeit manipulieren – also zumindest die wahrgenommene Dauer beeinflussen. Um damit zu beginnen, müssen wir eine Wartephase verstehen.

Wie ein verbreitetes Modell in der westlichen Philosophie feststellt, ist Zeit endlich. Sie hat einen Anfang und ein Ende und besteht aus unzähligen Einzeleindrücken, die ebenfalls wieder einen eigenen Anfang und ein Ende haben – so auch eine Wartephase. Wartephasen lassen sich sogar noch weiter aufteilen, nämlich in passive und aktive Phasen. Diese Aktivität kann rein mental sein (denken, verstehen, …) oder auch etwas Physisches. Innerhalb der passiven Phase hat ein Benutzer keine Kontrolle über die Wartezeit. Man hat keine Wahl und muss die Wartezeit so ertragen, wie sie ist. Die passive Phase ist für alle Beteiligten gefährlich. Innerhalb dieser Phase schaltet das Gehirn auf Leerlauf, da keine anderen geeigneten Alternativen zur Verfügung stehen. Bei einem Computer würde man sagen, er ist im Idle-Modus und schaltet den Bildschirmschoner an. In der passiven Phase ist man allein mit sich selbst, man erfährt einen Kontrollverlust und es gibt eigentlich nur die Alternative, den Prozess abzubrechen.

Entsprechend einer Studie des MIT wird eine passive Wartephase als etwa 36 Prozent länger wahrgenommen als die objektiv vergangene Zeit. Wir können das bestimmt alle bestätigen, da wohl jeder von uns irgendwann einmal rein passiv warten musste, ganz ohne Lesezirkel oder Smartphone. Wenn man Spaß hat, vergeht die Zeit im Flug. Als Designer sollten wir daher alles Mögliche dafür tun, unsere Benutzer so lange wie möglich im aktiven Modus zu halten! Die aktive Phase gehört ebenso zur Wartephase wie die passive, aber sie wird nicht als Wartezeit wahrgenommen. Man ist beschäftigt und hat die Kontrolle über die Zeit, ist produktiv!

Es gibt allerdings Möglichkeiten [3], die Zeiterfahrung zu tunen und für den Benutzer angenehmer zu gestalten. Kombiniert mit dem erlernten psychologischen Know-how kann man die Wartezeiten kürzer erscheinen lassen als sie eigentlich sind.

Präventivstart

Der Präventivstart oder Preemptive Start (Abb. 2) ist eine Möglichkeit, die Wartezeit durch verschieben des Startpunktes zu verkürzen. Dabei wird die Wartephase durch eine aktive Phase eröffnet, die so lange wie möglich aufrechterhalten wird. Die ursprüngliche Wartephase wird nicht wirklich verkürzt. Da die meisten Menschen die aktive Phase nicht als warten ansehen, kann somit der gefühlte Start in Richtung des Endes der Wartephase verschoben werden. Die Wartezeit erscheint also kürzer, als sie ist.

Abb. 2: Präventivstart – der Start wandert zum Ende

 

Sinnvolle Aufteilung

Eine hybride Technik ist die sinnvolle Aufteilung oder Meaningful Diversion (Abb. 3). In diesem Szenario teilt man einen lang andauernden Prozess in mehrere sinnvolle Einheiten auf. Diese Einheiten sind einzelne Präventivstarts. Während der Benutzer also arbeitet und sich aktiv betätigt, werden im Hintergrund Daten vorgeladen oder bereits verarbeitet. Statt eines Big Bangs, der den Benutzer lange im passiven Modus warten lässt, wird der Benutzer durchgehend beschäftigt und somit die Wartezeit gefühlt verkürzt. Diese Technik wird im sog. Wizards-Pattern verwendet, bei dem z. B. ein langes Formular in mehrere semantische Einheiten aufgeteilt wird.

Abb. 3: Sinnvolle Aufteilung – eine Reihe von Präventivstarts

 

Frühzeitiger Abschluss

Die nächste Methode ist der frühzeitige Abschluss oder Early Completion (Abb. 4). Genauso, wie man beim Präventivstart den Start in Richtung des Endes verschiebt, wird analog beim frühzeitigen Abschluss das Ende näher an den Start verschoben. Auch hier wird dem Benutzer das Gefühl vermittelt, dass die Wartephase schnell endet. Der frühzeitige Abschluss beginnt mit der passiven Phase, aber schiebt den Benutzer so schnell wie möglich in die aktive Phase, die, wie wir wissen, nicht als warten wahrgenommen wird. YouTube und die meisten Streamingdienste verwenden diese Methode des frühzeitigen Abschlusses: Wenn man auf den Play-Button eines Videos klickt, muss der Benutzer nicht warten, bis das Video vollständig geladen ist. Das Video startet unverzüglich, sobald irgendetwas Abspielbares im Puffer ist. Der Benutzer wird sehr schnell in die aktive Wartephase versetzt. Psychologie oder Magie, wie ihr wollt. Nachfolgend schauen wir uns einige Beispiele aus der Praxis an.

Abb. 4: Frühzeitiger Abschluss – alles hat ein Ende

 

Skeleton Screens

Weit verbreitet ist das Pattern der sogenannten Skeleton Screens bzw. Skeleton UIs (Abb. 5). Diese präsentieren uns bereits während des Ladevorganges strukturell einen Platzhalter für den Content. Der Platzhalter wird sukzessive befühlt und lässt uns glauben, kurz vorm Ende der Wartezeit – dem vorzeitigen Abschluss – zu stehen. Skeleton Screens verschieben den Focus auf den zu ladenden Content und weg von der Tatsache, dass gerade geladen wird. Das Anzeigen eines Skeleton UIs bevor sich der eigentliche Inhalt präsentiert, fühlt sich schneller an, als dies beim gleichzeitigen Anzeigen nach dem Prinzip eines „Big Load Upfront“ der Fall wäre. Skeleton Layouts sind auf Facebook, Slack etc. äußerst populär und jetzt wissen wir auch, warum.

Abb. 5: Skeleton Screens – alle Augen auf den Content

 

Optimistic UI

Einen Präventivstart können wir mit einer Technik namens Optimistic UI simulieren (Abb. 6). Dieses Pattern kann man als eine harmlose Lüge bezeichnen, Instagram z. B. setzt dieses Pattern äußerst geschickt ein. Die App gibt uns vor, fleißig zu arbeiten. Klickt man auf die Schaltfläche Gefällt mir, dann funktioniert es immer, auch wenn man beispielsweise offline ist. Die App gibt ein Versprechen, dass die gewünschte Aktion auch irgendwann wirklich durch- und zum Erfolg geführt wird. Angezeigt wird das fertige, das erwartete Ergebnis. Durch diesen Trick wird ein UI reaktiver und performanter wahrgenommen, obwohl die Arbeit im Hintergrund noch gar nicht wirklich beendet ist. Nur nicht beim Lügen erwischen lassen!

Abb. 6: Optimistic UI – lie to me …

 

Critical CSS

Ein Begriff ist zurzeit in aller Munde: First Meaningful Paint. Damit wird der Zeitpunkt bezeichnet, an dem der Benutzer den wichtigsten Inhalt einer Website als sichtbar erfasst.

Abb. 7: Wichtige Momente beim Laden von Webseiten

 

Der First Meaningful Paint ist allerdings nur ein Teil einer ganzen Serie von Events, wie Abbildung 7 zeigt. Zuerst beginnt die Navigation, an dieser Stelle sehen wir noch nichts. Im nächsten Schritt folgt der First Paint, jetzt kommt zum ersten Mal Leben in die Bude und auf den Bildschirm. Werden jetzt auch noch Teile der Website sichtbar, spricht man vom First Contentful Paint. Nach diesem First Meaningful Paint stellt sich der Status Visually Ready ein: Die Seite sieht schon fast fertig aus. Der Zyklus wird mit Fully Loaded abgeschlossen. Der First Meaningful Paint stellt dabei psychologisch eine besondere Komponente in diesem Ensemble dar, da der Benutzer genau an dieser Stelle zum ersten Mal erfasst, wohin die Reise geht.

Wie kann man also möglichst schnell zu einem aussagekräftigen First Meaningful Paint gelangen? Wir nutzen die Technik des frühzeitigen Abschlusses und schieben das Ende in Richtung des Starts. Dabei geben wir dem Benutzer das Gefühl, es sei schon (weitestgehend) alles fertig. Unterstützen können wir das, indem wir den Code der Webseite so programmieren, dass der Bereich above the Fold – also der sichtbare Bereich – zuerst lädt. Der Begriff kommt aus dem Druckjargon. Ist eine Zeitung gefaltet, ist nur der obere Bereich der Zeitung sichtbar. Im Webdesign wird als Fold die untere Kante des Viewports bezeichnet. Websitebereiche, die sich unter der Falz befinden, können erst durch Scrollen gesehen werden. Wird also der Bereich above the Fold zuerst geladen, bekommt der Besucher der Website in kürzester Zeit ein zufriedenstellendes Ergebnis angezeigt, das er sich ansehen kann. Danach kann der Websiteinhalt below the Fold geladen werden.

Aus einer Eye-Tracking-Studie der Nielsen Norman Group resultierte, dass Besucher, wenn die Above-the-Fold-Inhalte einer Webseite zuerst geladen werden, diesen rund 20 Prozent ihrer Zeit widmen. Besucher, bei denen dieser Bereich nicht sofort zur Verfügung steht, wenden nur 1 Prozent ihrer Zeit für die Betrachtung dieser Inhalte auf.

Die Technik des Critical Path CSS möchte ich daher an dieser Stelle ein wenig detaillierter beleuchten.

Achtung: Technik!

Genau wie extern referenzierte JavaScript-Dateien, blockieren auch die im Kopfbereich einer HTML-Seite referenzierten CSS-Stylesheets (eingebunden via ) den Aufbau der Seite, bis vom Browser alle Stylesheets angefordert, empfangen, heruntergeladen und analysiert worden sind. Bis dahin bleibt die Seite leer. Dieses Verhalten ist notwendig, damit der Browser das Layout der Seite berechnen kann. Leider bedeutet dies, dass unsere Benutzer mitunter so lange warten müssen, bis alle Dateien heruntergeladen wurden. Erst dann kann der Browser überhaupt erst mit dem Rendern der Seite beginnen. Bei wirklich großen CSS-Dateien oder wenn z. B. UI-Frameworks eingesetzt werden, kann einige Zeit verstreichen, bis alles heruntergeladen ist.

Glücklicherweise gibt es eine clevere Technik, die es uns ermöglicht, die gefühlten Ladezeiten (bzw. die gefühlte Performance) unseres UIs zu optimieren und die Performanceblockaden zumindest gefühlt zu minimieren. Diese Technik wird als Critical Path CSS bezeichnet.

Der kritische Renderingpfad beschreibt die Schritte, die der Browser während des Renderns einer Seite ausführt. Die Idee dahinter ist, dass die Website den Inhalt des für den Benutzer sichtbaren Bildschirmbereichs in den ersten paar TCP Responses erhalten soll. Dabei werden dem bestehenden CSS-Sheet alle notwendigen Klassen entnommen, die zur Darstellung des initial sichtbaren Bereichs der Website notwendig sind. Um den Blockadeeffekt zu reduzieren, wird das CSS-Extrakt im Kopf der HTML-Datei eingebettet. Also ein Teil inline und den Rest wie üblich in einer CSS-Datei.

Das bedeutet, dass wir initial nur eine minimale CSS-Teilmenge laden müssen, um den sichtbaren Teil der Seite über alle Breakpoints zu rendern. Der Rest des CSS-Codes kann im Anschluss asynchron geladen werden z. B. via JavaScript – aber dazu später mehr.

Der Inline-Teil (also direkt im <head> via <style>) beinhaltet alles, was zum Rendern des sichtbaren Bereichs (above the Fold) notwendig ist (Listing 1). Dieser Teil wird als Critical bezeichnet. Der Begriff stammt von Ben Edwards, der diese Teile im CSS mit Critical angegeben hat.

<!doctype html>
<head>
  <style> /* inlined critical CSS */ </style>
  …
</head>
<body>
  ...body goes here
</body>
</html>

 

Doch wie kommen wir zu unserem Critical Path CSS? Um die notwendigen CSS-Klassen zu bestimmen, muss das DOM der Website vollständig durchlaufen werden. Es muss eine Liste aller Styles erfasst werden, die momentan für jedes sichtbare Element im jeweiligen Viewport benötigt werden. Das manuell zu tun, wäre mehr als mühsam. Außerdem gibt es eine Reihe von großartigen Tools, die dies automatisch für uns tun. Exemplarisch schauen wir uns an dieser Stelle das Tool Critical von Addy Osmani an. Auf dessen GitHub-Seite gibt es ein übersichtliches Tutorial dazu. Critical lässt sich recht einfach in eine vorhandene Build-Pipeline einhängen, wie nachfolgend z. B. anhand des Task Runners Gulp erörtert wird.

Gehen wir davon aus, dass wir einige HTML-Quellen und ein zugehöriges Gulpfile haben (Gulpfile.js). In einem ersten Schritt installieren wir via NPM das Critical-Modul, das uns letztendlich die Arbeit abnehmen wird, den Critical-Path-CSS-Code für uns zu erzeugen. Dazu wechseln wir zuerst in das Verzeichnis unserer Web-App:

$ cd myapp
$ npm install critical —save-dev

Nach diesem Schritt können wir das neu installierte Modul in unserem Gulpfile referenzieren:

var critical = require(‚critical');

Durch die Referenz lässt es sich jetzt im Build-Prozess innerhalb eines Tasks verwenden. In einem nächsten Schritt erstellen wir nun einen Gulp-Task mit dem Namen criticalCSS:

gulp.task('criticalCSS', ['build'], function () {
 … 
});

Bevor die Schritte zur Generierung des CriticalCSS-Codes ausgeführt werden, lassen wir den criticalCSS-Task einen normalen Build durchführen, der je nach Konfiguration alle möglichen Optimierungen und Kopiervorgänge durchführt und das optimierte CSS in den Distributionsordner überführt (z. B. dist | styles | styles.css). Um das zu bewerkstelligen, wird der Name eines bestehenden Build-Tasks als zweites Argument in den Aufruf des criticalCSS-Tasks übergeben. Jetzt ist es an der Zeit, den Task zu konfigurieren (Listing 2).

gulp.task('criticalCSS', ['build'], function (cb) {
  critical.generate({
    inline: true,
    base: 'dist/',
    src: 'index.html',
    dest: 'dist/index-critical.html',
    minify: true,
    width: 320,
    height: 480
  });
});

 

Was wir jetzt haben, ist ein fertiger Task, der uns automatisch das notwendige Critical Path CSS in eine neue Datei im Distributionsordner mit dem Namen index-critical.html generiert. Den Prozess startet man mit folgendem Aufruf:

gulp criticalCSS

In diesem einfachen Beispiel wird die Größe eines gängigen mobilen Viewports verwendet. Die Breite von 320 Pixeln und die Höhe von 480 Pixeln geben dabei die Größe des Viewports an, dessen Above the Fold CSS wir benötigen. Der minify-Parameter sorgt dafür, dass der im Bereich unserer Website integrierte Inline-CSS-Code auch minifiziert wird, um schnellere Ladezeiten zu gewährleisten.

Hinter den Kulissen verwendet dieses Plug-in PhantomJS, einen sogenannten Headless Browser, um das erforderliche kritische CSS zu ermitteln. Die Webseite wird unsichtbar geladen und auf das optimale kritische CSS hin analysiert. Dieses Feature macht das Plug-in auch in Bezug auf verschiedene Bildschirmgrößen äußerst flexibel, da in der Konfiguration auch unterschiedliche Bildschirmabmessungen angeben werden können. Diese werden dann entsprechend in Critical CSS überführt. Die Konfiguration für mehrere Viewports ändert sich wie in Listing 3 dargestellt.

gulp.task('criticalCSS', ['build'], function (cb) {
  critical.generate({
    inline: true,
    base: 'dist/',
    src: 'index.html',
    dest: 'dist/index-critical.html',
    minify: true,
    dimensions: [{
      width: 320,
      height: 480
    },{
      width: 768,
      height: 1024
    },{
        width: 1280,
        height: 960
    }],
  });
});

 

Nach Abschluss des Gulp-Tasks wird im Zielordner eine Datei mit Namen index-critical.html angelegt. In dieser Datei wird für moderne Browser in cleverer Art und Weise dafür gesorgt, dass unser extern referenziertes CSS uns auch wirklich nicht blockierend in die Quere kommt:


Das link-Tag wurde auf elegantem Weg deaktiviert, da das rel-Attribut auf preload gesetzt wurde. Damit wird die CSS-Datei nicht geladen. Dass sie letztendlich doch noch geladen wird, dafür sorgt ein kleines Inline JavaScript, das das rel-Attribut auf stylesheet setzt, nachdem das DOM fertig gerendert wurde. Sollte beim Benutzer kein JavaScript zur Verfügung stehen bzw. ein älterer Browser verwendet werden, legt das Plug-in auch eine NoScript-Variante und ein Polyfill an.

Wie schnell die Zeit vergeht

Tempus fugit, wie der Lateiner sagt, und auch dieser Artikel kommt zu seinem Ende. Zeit ist ein kurioses Konstrukt und noch kurioser ist, wie wir Zeit erleben bzw. unser Zeiterleben beeinflusst werden kann. Technisches Performancetuning ist wichtig und sinnvoll. Allerdings darf die menschliche Komponente nicht unterschätzt werden. So manche teure Millisekunde, die aus Codeperformancetunings herauskommt, kann mit dem richtigen psychologischen Ansatz ggf. schon durch geschickte User Experience bereits im Vorfeld gewonnen werden. Es ist wichtig zu verstehen, dass es dem Benutzer um die wahrgenommene Performance, also die subjektive Zeitwahrnehmung geht. Mit den Worten von Leo Tolstoi komme ich nun zum Ende: „Alles nimmt ein gutes Ende für den, der warten kann.“

Weitere Links & Literatur
[1] Fotografie von R. C. James, entnommen aus: Lindsay, Peter H.; D. A. Norman: „Human Information Processing“, New York (Academic Press) 1977
[2] Wahrnehmung und Aufmerksamkeit. HERBERT HAGENDORF et al.; Springer-Verlag, 20.04.2011
[3] Designing and Engineering Time; Steven C.Seow; 2008 Pearson Education Inc.

Top Articles About Web Design & Development

MEHR INFOS ZUR WEBINALE?

JETZT NEWSLETTER ABONNIEREN

Programm-Updates der Webinale